スクラムガイドとのDiffを取ってみた

はじめに

こんにちは、DevOps導入支援担当の藤村です。

私の主な業務はDevOps導入支援事業の推進ですが、その傍らで社内のアジャイル開発支援のような活動も行なっています。先日とあるプロジェクトの進め方について相談を受けたので、その際にやったことをご紹介します。

プロジェクトの状況、課題

状況

• プロジェクトとしては一段落したところ
• 次のフェーズの開発に向けて、改善したいと考えている
• スクラムのプラクティスを数多く取り入れているが、一部実施していないプラクティスもある

メンバーが感じている課題

• フェーズ単位のふりかえりを行なったところ、以下のような課題がメンバーから上がってきた(開発プロセスが関係ありそうな項目を抜粋)
  • 進捗が見えづらかった
  • 見積もりが甘かった
  • 長期計画を立てることが難しかった
  • 非機能要件が疎かになってしまった
  • 全体的に余裕がなかった
  • マンパワーに頼ってしまうことがあった

やったこと

以下の２つを実施しました。

1. アジャイル開発の知識レベルを揃える
2. スクラムガイドとのDiffを取る

1. アジャイル開発の知識レベルを揃える

事前にヒアリングしたところ、アジャイルコーチをつけたプロジェクトでみっちりスクラムをやってきたメンバーから、今までスクラムを実践したことが無いというメンバーまでいて、チーム内でアジャイル開発の知識レベルに差があることが分かったため、知識レベルを揃えるために勉強会を開催しました。

ふりかえりでは見積もりや計画に関する課題が多かったため、まずはその部分にフォーカスした内容となっています。 [slideshare id=108331216&doc=aep2018-180802072927]

2. スクラムガイドとのDiffを取る

次に、スクラムガイドと現状の開発プロセスとのDiff(差分)を取りました。これは、完全なスクラムを実践するためにやったわけではありません。

当たり前の話ですが、完全なスクラムの実践を目指すような、手段が目的化してしまうこと自体には価値がありません。一方で、スクラムは過去のうまくいったパターンをマイニングして抽出して作られたこともあって、非常に良くできたフレームワークであり、一部を改変すると必ず何かしらの影響が出るように作られています。

スクラムを実践しているけど何だかうまくいかないという時は、スクラムガイドとの差分に解決のヒントが潜んでいることがよくあります。そのヒントを探る意味で、Diffを取ってみました。

具体的には、以下のような差分が抽出できました。

スクラムチーム

プロダクトオーナー

• プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。
  • プロダクトの価値の最大化に責任を持てていたか？
• プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見える化されている。
  • 優先順位の並び順を決めれていたか？

開発チーム

• ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書きはない。
  • 役割に応じた肩書きはなかったか？

スクラムイベント

スプリントプランニング

• 開発チームがスプリントの最初の数日間で行う作業については、スプリントプランニングで作業に分解する。作業の単位は 1 日以下にすることが多い。
  • 最初の数日間で行なう作業は、プランニングの時間で作業に分解しているか？
  • 作業の単位は1日以下にしているか？

デイリースクラム

• 開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。
  • スプリントゴールとスプリントバックログの進捗を検査しているか？
• 開発チームは、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけない。
  • スプリント終了までに期待されるインクリメントを作成できるかを毎日把握できているか？

スプリントレビュー

• インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。
  • フィードバックや協力を引き出すことを目的としているか？
  • 受け入れ条件を満たしているかの確認が目的になっていないか？
• プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。
  • プロダクトオーナーが説明しているか？
  • プロダクトオーナーに開発チームが説明していないか？

スプリントレトロスペクティブ

• スクラムマスターは、このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。
  • 参加者は目的を理解できているか？

作成物

プロダクトバックログ

• プロダクトに対する変更要求の唯一の情報源である。
  • 唯一の情報源になっているか？
• プロダクトバックログは動的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。
  • 絶えず変化しているか？

スプリントバックログ

• スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている。
  • 必要な作業がすべて見える化されているか？
• 継続的改善を確実なものとするために、前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1つは含めておく。
  • プロセス改善策は1つ以上含められているか？
• スプリントバックログには、開発チームがスプリントで行う作業がリアルタイムに反映される。
  • リアルタイムで更新できているか？

作成物の透明性

作成物の透明性の確保

• スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。作成物の透明性が不完全であれば、こうした決定には不備があり、価値は低減し、リスクが高まる可能性がある。
  • 作成物(プロダクトバックログ、スプリントバックログ、インクリメント)の透明性は確保されているか？

「完成（Done）」の定義

• プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるかもしれないが、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。
  • 「完成」の定義が存在するか？
  • 作業が完了したかどうかの評価に使われているか？

その後のステップ

差分を洗い出した後のステップは、チームのメンバー自身に考えてもらいます。

• これらの差分がふりかえりで上がった課題の要因となっていないか
• これらの差分は自ら選択していたことか、なし崩し的にそうなってしまっていないか
• これらの差分が原因で起こり得る課題と、差分を無くすコストを比較して判断できているか

重要なのは、スクラムガイドに書いてある通りのやり方に盲目的に従うのではなく、スクラムガイドと現状の進め方の差分を認識し、今後も同じやり方を継続するか、やり方を変えるかをメンバー自らが選択することです。

おわりに

私の一旦の支援はここまでとしました。この後メンバー自らが選択したことの中でお手伝いできることがあれば、今後も継続的に支援していきたいと考えています。